1.07. Методологии
Методологии
Когда мы говорим о методологиях сейчас, то чаще всего думаем о Scrum, Agile, Waterfall, DevOps и прочих непонятных английских словах. Это всё - способы организации труда, и они появились тогда, когда люди начали работать вместе над сложными задачами. В какой-то момент стало понятно, что для успешного завершения большого проекта, простых знаний недостаточно. Нужны правила, процессы, роли и обратная связь.
В начале XX века наука была делом одиночным, либо коллективы были совсем малыми. Учёные сами ставили цели, вели исследования, проверяли результаты и публиковали статьи. Другие учёные читали такие статьи, и пробовали проверять, выявляли что-то новое и тоже публиковали результаты своих исследований. Работа была свободной, гибкой, но мало масштабируемой. Однако именно в этот период были заложены основы научного метода (гипотеза → эксперимент → вывод), документации и обмена опытом через публикации. Можно назвать это самыми ранними методологиями - способами получения знаний.
Большинство государств были либо классовыми, а уровень образования был нереально низок, из-за чего о каком-то развитии технологий силами корпораций речи идти не может. Буржуазия, как и аристократический слой общества, управляла рабочими и крестьянами исключительно на износ. К тому же, бушевали войны, революции, экономический кризис, что сильно мешало гражданскому обществу раскрываться, и поэтому первая половина XX века является довольно мрачным временем.
С началом Второй мировой войны всё поменялось. Нужно было решать огромные задачи за короткое время - расшифровка Энигмы, ядерная физика, баллистические ракеты. Появились первые команды специалистов, где математики формулировали задачи, инженеры строили машины, а операторы (часто женщины) выполняли вычисления. Напоминает современное деление ролей? Вот тогда и возникла необходимость как раз разделять роли, стандартизировать вычисления и использовать повторяемые процедуры. Можно назвать это первым опытом проектного управления, пусть и без названия.
Когда появились первые компьютеры, программирование стало частью инженерной задачи. Программы писались под конкретное железо, тестирование выполнялось вручную, а документация отсутствовала, либо была минимальной. Но уже в этот период стали формироваться элементы будущих метологий - определение требований, документирование кода, обратная связь от пользователей. Большинство проектов в 1950-1970-х годах были государственными, поэтому контроль и отчётность были жёсткими. Здесь и началась эпоха традиционных методологий.
Модель «Водопад» («Waterfall») формализована была в 1970 году Уинстоном Ройсом. В своей статье он описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели, показав, что модель может быть доработана до итеративной. В такой традиционной методологии этапы были:
анализ → проектирование → реализация → тестирование → внедрение
Такой подход подходит для предсказуемых проектов, к примеру, оборонных, с особенностями в виде жёстких сроков, чётких этапов и минимальными изменениями в процессе. Актуально было, потому что бизнес только начинал осознавать ценность софта, не хватало опыта в управлении цифровыми продуктами, бюджеты были огромны, а ошибки - недопустимы. Но вскоре стало ясно - «Водопад» работает плохо, если требования меняются. А в реальном мире они всегда меняются.
В 1980-х практически произошла революция IT-сферы - персональные компьютеры, новые ОС, графический интерфейс и доступность для широких масс. Бизнес начал осваивать IT, тогда и появились первые корпорации вроде Microsoft. Проектов стало больше, сроки - короче, требования - сложнее. Традиционные методы с этим не справлялись. Проекты срывались, бюджеты взлетали, команды выгорали, а заказчики оставались недовольны. История всегда показывала, что всё время наказывая работников, к положительному ожидаемому результату не придёшь.
И в такой период рождались спиральные модели, итерационные модели, прототипирование. Люди начали понимать, что софт - это не завод, а живая система, которую нельзя запланировать полностью заранее. Здесь уже не работают методы промышленных методологий, когда просто нужно работать больше и продукция увеличится, нет. Кстати, многие до сих пор такого не признают, и можно встретить на практике заказчиков-бизнесменов или чиновников, которые воспринимают IT как разработку чего-то физического.
В 2001 году группа программистов подписала Манифест Agile: «Мы раскрываем более эффективные методы разработки программ, практикуя их и помогая другим это делать. Через эту работу мы пришли к следующим ценностям:
-
Люди и взаимодействие важнее процессов и инструментов;
-
Работающий софт важнее исчерпывающей документации;
-
Сотрудничество с заказчиком важнее согласования условий контракта;
-
Готовность к изменениям важнее следования первоначальному плану.»
Так родились методологии:
- Scrum - итеративная модель с регулярными встречами и ретроспективами.
- Kanban - визуализация потока задач.
- Extreme Programming (XP) - акцент на тестировании и читаемости кода.
- Lean - минимизация потерь и максимальная ценность.
Agile стал не просто методологией, а культурой. Он переформировал отношения внутри команд, отношение к нагрузке, к ответственности, к саморазвитию.
Agile быстро распространился, но и он столкнулся с проблемами. Формализация привела к появлению новых бюрократических подходов, выгорание сотрудников осталось, несмотря на гибкость, а при управлении десятками команд возникло ещё больше проблем, ведь проекты всё расширялись.
Тогда появились новые методологии - Scaled Agile Framework, «масштабируемый Agile», как попытка применить философию к большим организациям; DevOps для объединения и автоматизации разработки и эксплуатации; появились отказы от точных строков в пользу итераций, и конечно удалённая работа с новыми форматами коммуникации. Во главу поставили софт-скиллы, психологическую безопасность, ментальную здоровье, системы лояльности, адаптивный менеджмент.
Методологии развивались вместе с людьми, которые их использовали. Они отражают не только технический прогресс, но и изменения в обществе, экономики и культуре труда. Сейчас IT стала частью всех отраслей, а софт уже не продукт, а инфраструктура. Поэтому, переходя в эту сферу из других - это бросится в глаза.